Upload operation using multiple connections

ABSTRACT

A client system requests to upload an input data stream to a server system. The input data stream is split to a sequence of chunks. The chunks are transferred in parallel by a number of connections from the client system to the server system. At the server system, the transferred chunks are merged into an output stream according to the sequence. The output stream represents the rebuilt input stream.

BACKGROUND

A deployment operation to a cloud platform commonly entails a transferof application binaries over a network from a user host to processingnodes of the cloud platform. The application binaries may vary in size.Also, networks through which the application binaries are transferredmay vary in speed and bandwidth. Nevertheless, the transfer of theapplication binaries takes a major portion of the whole deployment time,compared to the time for the actual processing of the binaries by theprocessing nodes. Thus, the network often acts as a bottleneck for thedeployment operation and may slow it down. Slow upload and deploymentmay negatively affect the user experience and could keep a session openfor long time, for example, up to several hours.

BRIEF DESCRIPTION OF THE DRAWINGS

The claims set forth the embodiments with particularity. The embodimentsare illustrated by way of examples and not by way of limitation in thefigures of the accompanying drawings in which like references indicatesimilar elements. The embodiments, together with its advantages, may bebest understood from the following detailed description taken inconjunction with the accompanying drawings.

FIG. 1 illustrates a process to upload data from a client system to aserver system using multiple connections, according to some embodiments

FIGS. 2A-B illustrates a process to upload a data file from a clientsystem to a server system using multiple connections, according to someembodiments.

FIG. 3 illustrates a client-server system architecture to deploy adeployable package from a client system to a server system of a cloudplatform using multiple connections, according to some embodiments.

FIG. 4 illustrates an exemplary computer system, according to someembodiments.

DETAILED DESCRIPTION

Embodiments of techniques for upload operation using multipleconnections are described herein. In the following description, numerousspecific details are set forth to provide a thorough understanding ofthe embodiments. One skilled in the relevant art will recognize,however, that the embodiments can be practiced without one or more ofthe specific details, or with other methods, components, materials, etc.In other instances, well-known structures, materials, or operations arenot shown or described in detail.

Reference throughout this specification to “one embodiment”, “thisembodiment” and similar phrases, means that a particular feature,structure, or characteristic described in connection with the embodimentis included in at least one of the one or more embodiments. Thus, theappearances of these phrases in various places throughout thisspecification are not necessarily all referring to the same embodiment.Furthermore, the particular features, structures, or characteristics maybe combined in any suitable manner in one or more embodiments.

A single connection may be shaped or limited to a certain speed. Forexample, networks may often be characterized by shaping and imposinglimitations on the speed of individual connections. The allowed speed ofthe individual connections may often be just a small portion of thewhole available bandwidth of the network. This may be done, to avoid acase where a single connection consumes major portion from the availablenetwork bandwidth, preventing other connections from utilizing thenetwork. For example, corporate networks may often impose suchlimitations, so that the available bandwidth is distributed more evenlyamong entities in the network. If the speed of the connection is forinstance 100 KB/sec, a file with approximately 3.6 GB size would betransferred or uploaded for an hour. With such speed, customerapplications of regular size could be uploaded or deployed to a cloudcomputing platform for an hour or more.

In the context of content transfer, deployment may include packaging orzipping the content to be deployed, transferring or uploading thepackaged content from a client system to an administrative server (e.g.,an orchestrator) of the cloud computing platform, optionallyun-packaging the packaged content, and transferring the content to afile system of the cloud computing platform, e.g., a cloud platformrepository. Today, a single network connection is used for bothtransfers—the transfer from the client system to the administrativeserver and, the transfer from the administrative server to the cloudplatform repository. While the transferring from the administrativeserver to the cloud platform repository may be running within a networkthat may be with higher speed (e.g., internal network of the cloudplatform provider), the transfer from a client system to theadministrative server often may suffer from network speed limitations.Using a single connection, limited in speed, for any upload or contenttransfer operation may negatively impact user experience. For example, adeploy session may be kept open for a long time on the administrativeserver. While the deploy session is open computing resources are beingconsumed increasing the total cost of ownership.

Although a single connection may be limited in speed, still multipleconnections from different programs may access the same Internetaddress. Speed of a deployment or any upload operation may be improvedby using the number of connections permitted for a particular networkand using those connections to one and the same address. In oneembodiment, a multiple connections protocol is implemented on top of theHTTP protocol. The multiple connections protocol supports transferringinput data over multiple HTTP connections in parallel. By transferringinput data over multiple connections in parallel higher speed of theupload or deploy operation may be achieved compared to transferring dataover a single one. With the multiple connections protocol, the speed ofthe data upload or transfer is limited by the available bandwidthcapacity instead of the speed of a single shaped connection. Therefore,maximum bandwidth of the network may be utilized for an upload operationby the multiple connections, according to some embodiments.

FIG. 1 illustrates process 100 to upload data from a client system to aserver system using multiple connections, according to one embodiment.At 110, a request for an upload operation is received. The uploadoperation to transfer a data file from the client system to the serversystem. The data file is an input data stream for the upload operation.In the context of data transfer, a data file may be viewed as a datastream as it is read and processed, for example, byte by byte. At 120,the input data stream is split into a sequence of chunks. A chunk is aportion of data from a data stream. The chunk further includes a chunkidentifier and a chunk size. The chunk identifier is a consecutivenumber of the portion of data in the data stream. Thus, the chunkidentifier represents the order of the chunk in the data stream andidentifies the chunk itself. Chunk identifiers may be used to restore orrebuild the input data stream at the server system. A chunk size mayrepresent the size of the portion of data represented by the chunk, inbytes, for example. Therefore, a chunk includes a portion of data from adata stream, a consecutive identifier of the chunk in the stream, and asize of the portion of data represented by the chunk. Chunks size may bepredetermined. For example, chunks size may be fixed to 8 KB. Size ofthe last chunk in the sequence of chunks may vary. The multipleconnections protocol may support also variable chunks size, according tosome embodiments.

At 130, the chunks are transferred from the client system to the serversystem by a number of connections. In one embodiment, the connectionsare based on a protocol from the Internet protocol suite on a levelhigher than the transport layer such as a protocol from the applicationlayer. For example, the connections may be based on Hypertext TransferProtocol (HTTP) or HTTP Secure protocol. The chunks may be transferredin parallel by the connections to speed up the upload operation. At 140,the input stream is rebuilt at the server system. The input stream isrebuilt by merging the chunks into an output stream according to thesequence.

FIGS. 2A-B illustrate process 200 to upload a data file from a clientsystem to a server system using multiple connections, according to oneembodiment. At 205, a request to upload the data file from the clientsystem to the server system is received. At 210, it is determinedwhether a single or multiple connections protocol is to be used for therequested upload operation. In one embodiment, the client systemdetermines whether to use single or multiple connections protocol basedon the size of the data file to be uploaded. For example, multipleconnections protocol may be used for data files with size above apredefined threshold, e.g., 5 MB. Whether a multiple connectionsprotocol is to be used may also depend on whether the client system isconfigured with a thread-safe connection manager.

Upon determining that the multiple connections protocol is to be usedfor the upload operation, at 215, determine a number of connections tobe created. In one embodiment, the number of connections may remainconstant for the whole span of the upload operation. In anotherembodiment, the number of connections may be intelligently increased ordecreased on the fly proportionate to demand. The intelligent adjustmentof the number of connections may depend on, for example, transfer speedand/or other parameters. For example, the number of connections may beiteratively increased upon determining that when a new connection isadded the transfer speed is increased. Thus, connections may beiteratively increased until the network bandwidth is optimally utilized.In one embodiment, a user of the client system may configure the numberof connections. Thus, the number of connections may be configurableparameter or intelligently adjustable on the fly.

Upon determining the number of connections to be created, at 220, ahandshake request from the client system is received at the serversystem. The handshake request specifying the number of connections. Thenumber of connections to be used for the upload operation. At 225, it ischecked whether the handshake request is accepted. In one embodiment,the server system may deny the request, for example, if the serversystem is not configured to communicate over the requested protocol fromthe client system. For example, the server system may not be configuredto communicate over the multiple connections protocol, then thehandshake is denied and the upload operation to be performed over thesingle connections protocol. When the handshake is accepted, at 230, aresponse is received from the server system. The response from theserver system specifying an upload operation identifier. The uploadoperation identifier to be referenced by the number of connections.Further, the response specifies a location, e.g., a uniform resourcelocator (URL), at the server system to be polled for status of theupload operation. For example, status is polled to determine whether theupload operation is still running or whether it is finished successfullyor not. In one embodiment, based on the upload operation identifier, thelocation at server system may be polled for status of the uploadoperation.

In one embodiment, initially the client system creates a single HTTPconnection from the client system to the server system. At 230, thenumber connections are created. Each connection from the createdconnections is associated with a connection identifier and the uploadoperation identifier for which the connection will transfer data. At245, a feeder thread is instantiated. Further, a number of connectionsender threads are instantiated. The feeder thread and the connectionssender thread may be created by the client system. Each connectionsender thread is associated with a corresponding connection from thenumber of created connections. In one embodiment, a connection senderthread is associated with a single connection from the createdconnections. Thus, the connection sender thread maintains a singleconnection to the server system through which chunks read by theconnection sender thread are sent. Maintaining a single connection by athread may be done for optimization purposes. When a single connectionis maintained by the connection sender thread, a single request to theserver system is executed for the chunks read by the connection senderthread as opposed to a separate request to the server system for eachread chunk, which could overload the server system.

At 250, a number of connection reader threads are instantiated. Eachconnection reader thread is associated with a corresponding connectionsender thread from the connection sender threads. Respectively, eachconnection reader thread associated with the corresponding connectionassociated with the connection sender thread. In one embodiment, theconnection reader threads may be created by the server system, uponcreating the connections and the connection sender threads. Threads,either connection sender or reader, perform processing related to theconnection for which the thread is created. For example, a thread readsdata from an input data stream, writes the data to the respectiveassociated connection, and sends the data through the connection.

At 255, the data file is read in chunks by the feeder thread to splitthe data file into a sequence of chunks. The feeder thread receives asinput data stream the data file. At 260, the feeder thread writes thechunks into a client buffer according to the sequence. The client buffermay be a queue on the client system that serves as cache for theconnection sender threads. When chunks written in the client bufferreach size bigger than a predefined threshold, further entries of chunksmay be blocked, according to one embodiment.

At 265, the connection sender threads read chunks from the client bufferand, concurrently, send the read chunks to the corresponding connectionreader threads. In one embodiment, a connection sender thread reads nextunread chunk from the client buffer and sends that chunk to acorresponding connection reader thread at the server system. Once theconnection sender thread sends the chunk, the connection sender threadreads next unread chunk from the client buffer. In parallel, one or moreother connection sender threads may read unread next chunks from theclient buffer and send them to corresponding connection reader threads.Thus, chunks are continuously read and sent in parallel by theconnection sender threads, reusing the same HTTP connections.

Upon reading the input data stream, at 270, the feeder thread notifyingthe number of connections that input data stream has been read. Forexample, the feeder thread may raise a flag indicating end of input datastream for upload. Upon determining that the client buffer is empty andthat the input data stream has been read, at 275, the connections areclosed. At 277, polling of the server for status of the upload operationis started. For example, upon determining that the client buffer isempty and that the input data stream has been read the client system maystart to poll the server for the status of the upload operation.

At 279, a connection reader thread reads a chunk sent by a correspondingconnection sender thread. In response to concurrently sending chunks bythe connection sender threads, the connection reader threadsconcurrently read incoming chunks sent by the connection sender threads.Once the connection reader thread reads the chunk sent by acorresponding connection sender thread, at 280, a check is performed todetermine whether the chunk is next in the sequence of chunks that isexpected at the server system. For example, it is determined based onthe consecutive number or identifier of the chunk in the sequence ofchunks. Upon determining that the chunk is next expected, at 281, thechunk is merged to an output stream according the sequence of chunks. At282, a number of server buffers are scanned for chunks with consecutivenumbers subsequent to the merged chunk. At 283, found chunks with thesubsequent consecutive numbers are merged to the output stream. Theinput data stream to be restored at the server system by merging thechunks into the output stream according to their order in the sequence

Upon determining that the chunk is not the next one expected, at 284,the chunk is stored to a corresponding server buffer from the number ofserver buffers. Each connection reader thread is associated with acorresponding server buffer. The number server buffers to store readchunks by the number of connection reader threads.

At 286, a check is performed to determine whether all chunks that aresent by the connection sender threads are processed by the connectionreader threads. When not all chunks that are sent by the connectionsender threads are processed by the connection reader threads, aconnection reader thread reads and processes next chunk received. Whenall chunks that are sent by the connection sender threads are processedby the connection reader threads, at 288, the input stream is rebuilt atthe server system by merging the chunks into the output stream accordingto the sequence. In one embodiment, the server buffers are searched forchunks with consecutive numbers that are expected next in the sequenceof chunks of the output data stream. When a chunk with consecutivenumber is missing in the server buffers, one of the connections waitsfor the missing chunk, while chunks incoming from the other connectionsare stored in corresponding server buffers. Since connections areexecuted in sessions, chunks transferred over a connection are receivedat the server system in the order in which the chunks have been sent.Thus, if one connection and the corresponding server buffer for theconnection are blocked, other connections may continue to transferchunks. Connection reader threads that have no more data to transfer arestopped once the server system is notified to clean its data structures.

Although process 200 include series of steps, it will be appreciatedthat the process 200 is not limited by the illustrated ordering ofsteps, as some steps may occur in different orders, some concurrentlywith other steps. For example, the connection reader and sender threadsmay process chunks concurrently. In some embodiments, the multipleconnections protocol supports deploying a deployable package from aclient system to a cloud platform over multiple HTTP connections inparallel to speed up the deployment.

FIG. 3 illustrates client-server system architecture 300 to deploy adeployable package 320 from client system 310 to server system 315 of acloud platform using multiple connections, according to one embodiment.In one embodiment, a request to deploy deployable package 320 isreceived at client system 310. The deployable package 320 to be deployedfrom client system 310 to server system 315 of a cloud platform vianetwork 305. Deployable package 320 may be associated with or bepertinent to one or more specific software applications, modules,components, features, services, etc. The deployable package may be anarchive file that includes, among other things, application binaries tobe deployed on the cloud platform. Examples of a deployable packageinclude, but are not limited to, Java ARchive (JAR), Web applicationARrchive (WAR), Enterprise Archive (EAR), Web Application Bundle (WAB),etc.

In various embodiments, a cloud platform is an on-demand runtimeplatform. A cloud platform may include functionality such as resourcepooling, where the computing resources of the cloud infrastructureprovider are pooled to serve multiple consumers using a multi-tenantmodel. Another functionality that the cloud platform may provide iselasticity that refers to the capability of the platform to elasticallyprovision and release computing resources to scale commensurate withdemand. The cloud platform may also expose a metering characteristicthat refers to the capability of the cloud platform to automaticallycontrol, monitor, report, and optimize resource usage at some level ofabstraction appropriate to the type of service, for example, storage,processing, bandwidth, and active user accounts, and so on.

A cloud platform can be viewed as containing both a physical layer andan abstraction layer. The physical layer may consist of the hardwareresources to support the cloud services being provided, and maytypically include a server, a storage unit, network components, and soon. The abstraction layer may include the software deployed across thephysical layer, which manifests the essential functionalities providedby a cloud platform. For example, the cloud platform may provide anapplication runtime, user interface (UI) development toolkits, internalconfigurations, cloud services such as a connectivity service, apersistence service, an identity service, a feedback service, a documentservice, etc. The functionality provided by the cloud platform can beused by customers of the cloud platform to develop and deploy softwareapplications on the cloud platform. In one embodiment, customers orconsumers of the cloud platform may provide one or more deployablepackages representing software applications to be deployed on the cloudplatform. In some embodiments, the software applications may bedeveloped using functionality of the cloud platform. Binaries containedin the deployable packages can be executed onto the cloud platform. Invarious embodiments, the cloud platform may also provide support for theapplication lifecycle process, for example, deployment, installation,provisioning and maintenance of applications that may be built,deployed, installed and run on the cloud platform. In one embodiment,the cloud platform may be platform-as-a-service implemented in Java.

In one embodiment, client system 310 may be a deploy http client ofserver system 315. Server system 315 may be an administrative serversuch as an orchestrator of the cloud platform, according to someembodiments. The administrative server may manage the lifecycle ofdeployed software applications on the cloud platform. The administrationserver deploys, starts, and stops the applications, among other things.The administration server may install applications on one or morevirtual machines (VMs), where the applications are accessed by endusers. The administration server may automatically provision more thanone VM to host one application, according to some embodiments.

Once the request to deploy deployable package 320 is received at clientsystem 310, client system 310 determines whether a single or multipleconnections protocol is to be used for the requested deploy operation.The single connection protocol supports one connection and thedeployable package or content to be uploaded is received with the firstPUT request. The response to the PUT request is the deploy operation anda status of the deploy operation. Both synchronous and asynchronousstrategies can be used. Client system 310 may request from server system315 synchronous and asynchronous deployment strategies. The synchronousdeployment strategy blocks the response from server system 315 until thedeployment operation finishes, successfully or with error. However, oncethe input stream has been restored at server system 315, server system315 may continue to process the output stream for deployment. Forexample, once the output stream is generated and stored on server system315, the output stream may be validated and transferred from serversystem 315 to a cloud repository. The cloud repository may be a centralfile system for the cloud platform where application and cloud platformbinaries may be stored. After generating the output stream, finishingdeployment may be time consuming for deployable packages with biggersize. Commonly, proxies of the cloud platform may close idle connectionsfor load balancing purposes, among others. For example, connections withtimeout above a predefined threshold may be closed by the proxies.Therefore, with the synchronous strategy, although the deployablepackage may be successfully transferred to server system 315, stilldeployment may fail due to blocking the response until the wholedeployment operation finishes. To avoid this, in one embodiment, clientsystem 310 may request asynchronous deployment strategy.

The multiple connections protocol uses asynchronous deployment strategyto avoid closing idle connections. With the asynchronous deploymentstrategy, server system 315 periodically returns deployment status,during deployment. Further, server system 315 returns a deploymentoperation identifier, once the deployment operation is started. Thedeployment operation identifier is used by client system 310 to pollserver system 315 for status of the deployment operation, for example,by a GET request.

Once client system 310 determines that multiple connections protocol isto be used for the requested deploy operation, the number of connectionsto be used is determined Client system 310 sends a handshake request toserver system 315 specifying the number of connections. For example, thehandshake request may be performed by a PUT request that include aheader specifying the number of connections. The header may indicate theprotocol to be used, e.g., single connections or multiple connectionsprotocol. The number of connections may be a maximum number ofconnections to be established between client system 305 and serversystem 315. When the deployment operation is accepted, server system 315sends a response specifying the upload operation identifier to be usedby the number of connections to be created. And also, the responsespecifies a location on server system 315 for status polling of thedeployment operation. In some embodiments, server system 315 may denythe deployment request when the specified connections are above apredefined threshold or the cloud platform is not working properly, forexample.

Once the deployment operation is accepted, client system 310 creates aninstance of demultiplexer, for example, demultiplexer 340. In turn,demultiplexer 340 instantiates and manages feeder thread 325 andconnections ‘1’, ‘2’, and ‘3’. Feeder thread 325 splits deployablepackage 320 into a sequence of chunks and stores the chunks into buffer330. The multiple connections ‘1’, ‘2’, and ‘3’ are created from asingle client system 310 to one and the same server system 315 of thecloud platform for a single deployment operation.

Further, demultiplexer 340 instantiates a connection sender thread foreach of the connections ‘1’, ‘2’, and ‘3’. For example, thread ‘3’ 332is associated with connection ‘3’. Thread ‘2’ 334 is instantiated totransfer data through connection ‘2’. Thread ‘1’ 336 is instantiated totransfer data through connection ‘1’. Thus, for a single deployoperation multiple connections ‘1’, ‘2’, and ‘3’ are created. Eachconnection ‘1’, ‘2’, or ‘3’ runs in a separate session to server system315. Sessions are authenticated by server system 315. Each connection‘1’, ‘2’, or ‘3’ runs in a separate session and is associated with acorresponding thread from threads ‘1’ 336, ‘2’ 334, and ‘3’ 332 thattransfer data. Feeder thread 325 reads data in chunks from deployablepackage 320 and stores the chunks into buffer 330. For example, feederthread 325 filled up buffer 330 with chunk ‘1’, chunk ‘2’, chunk ‘3’,and chunk ‘4’ read from deployable package 320. Threads 1′ 336, ‘2’ 334,and ‘3’ 332 in parallel read chunks from buffer 330. Feeding or storingchunks to buffer 330 by feeder thread 325 is faster compared to eachthread from threads 1′ 336, ‘2’ 334, and ‘3’ 332 reading chunks directlyfrom deployable package 330. Thus, feeder thread 325 accelerates theprocessing of loading threads ‘1’ 336, ‘2’ 334, and ‘3’ 332 with datachunks for transfer.

In one embodiment, in parallel, in response to creating connections ‘1’,‘2’, and ‘3’, server system 315 creates an instance of a multiplexer,for example, multiplexer 350. In turn, multiplexer 345 instantiates areader thread for each sender thread ‘1’ 336, ‘2’ 334, and ‘3’ 332,respectively. For example, sender thread ‘1’ 336 sends chunks to readerthread ‘1’ 366, and reader thread ‘1’ 366 reads chunks sent by senderthread ‘1’ 336, respectively. Sender thread ‘2’ 334 sends chunks toreader thread ‘2’ 364, and reader thread ‘2’ 364 reads chunks sent bysender thread ‘2’ 334. Sender thread ‘3’ 332 sends chunks to readerthread ‘3’ 362, and reader thread ‘3’ 362 reads chunks sent by senderthread ‘3’ 332. Sender threads 332-336 continuously and in parallel readchunks from buffer 330 and send those chunks via network 305 tocorresponding reader threads 362-366. For example, thread 336 readschunk ‘1’ 346 from buffer 330 and sends chunk ‘1’ 346 through connection‘1’ to thread ‘1’ 366. Thread 334 reads chunk ‘2’ 344 from buffer 330and sends chunk ‘2’ 344 through connection ‘2’ to thread ‘2’ 364. Thread332 reads chunk ‘3’ 342 from buffer 330 and sends chunk ‘3’ 342 throughconnection ‘3’ to thread ‘3’ 362.

Further, multiplexer 350 creates buffer 352 associated with readerthread ‘1’ 366, buffer 354 associated with reader thread ‘2’ 364, andbuffer 356 associated with thread ‘3’ 362, respectively. Reader threads362-366 either store read chunks into corresponding buffers 352-356 ormay directly write the read chunks to output data stream 370. When areader thread from reader threads 362-366 reads a chunk sent by acorresponding sender thread, from sender threads 332-336, the readerthread notifies multiplexer 350 indicating the consecutive identifier ofthe read chunk. Multiplexer 350 may determine based on a counter whetherthe consecutive identifier is next one expected to be merged or appendedto output stream 370. In one embodiment, a current value of the countermay indicate the next chunk expected. For example, once a chunk has beenmerged to output stream 370, the counter is incremented to indicateconsecutive identifier of the next chunk expected. Once multiplexer 350determines that the chunk is next expected, the reader thread directlywrites the chunk to output stream 370 instead of to a correspondingserver buffer from server buffers 352-356. Alternatively, whenmultiplexer 350 determines that the chunk is not the next expected, thereader thread stores the chunk into corresponding server buffer frombuffer 352-356. Once the next expected chunk is merged to output stream370, the counter is incremented, and multiplexer 350 based on indextable 355, determines whether the chunk with next consecutive number isstored in one of buffers 352-356. For example, once chunk ‘6’ isreceived by thread 362, chunk ‘6’ may be directly merged to outputstream 370 and multiplexer 350 may search into the index table 355 todetermine whether subsequent chunks are available, e.g., stored inbuffers 352-356. In the illustrated example in FIG. 3, multiplexer 350identifies that chunks ‘7’, ‘8’, ‘9’, and ‘10’ are available in buffers352-356. Based on index table 355, multiplexer 350 identifiescorresponding server buffers 352 and 354 that stores chunks ‘7’, ‘8’,‘9’, and ‘10’. Multiplexer 350 reads chunks ‘7’, ‘8’, ‘9’, and ‘10’ fromthe identified server buffers 352 and 354 and write them to outputstream 370, according to their consecutive identifiers.

As illustrates in FIG. 3, connection ‘3’ may be slower than connection‘1’ and ‘2’. Accordingly, thread 332 and thread 362 of connection ‘3’are slower than other threads associated with connection ‘1’ and ‘2’,respectively. Connection ‘3’ managed to transfer chunk ‘3’, but chunk‘6’ is yet to be transferred. Since sender threads 336 and 334, andreader threads 366 and 364 are faster, buffer 352 and buffer 354 arealready filled up. Since chunk ‘6’ is missing in index table 355 ofmultiplexer 350, the rebuilt of the input stream may be blocked untilchunk ‘6’ arrives at server system 315. The buffer of a slow connectionwould not be filled up with data from other connections, if previouschunks are not yet received to prevent a deadlock. For example, chunk‘11’ would not be stored in buffers 352-356 until chunk ‘6’ arrives.

In one embodiment, output stream 370 representing the restored originalinput stream is stored on server system 315. Once the output stream isgenerated and stored on server system 315, the output stream may bevalidated and transferred from server system 315 to a cloud repository.The cloud repository may be a central file system for the cloud platformwhere application and cloud platform binaries may be stored.

In some embodiments, as an alternative to rebuilding the data on theserver system 315 a Random Access File (RAF) may be used. This willsimplify the logic since server buffers 352-356 and index table 355would not be necessary. Instead threads may write the chunks directly ona file system of server system 315 by calculating the offset of eachchunk.

Some embodiments may include the above-described methods being writtenas one or more software components. These components, and thefunctionality associated with each, may be used by client, server,distributed, or peer computer systems. These components may be writtenin a computer language corresponding to one or more programminglanguages such as, functional, declarative, procedural, object-oriented,lower level languages and the like. They may be linked to othercomponents via various application programming interfaces and thencompiled into one complete application for a server or a client.Alternatively, the components maybe implemented in server and clientapplications. Further, these components may be linked together viavarious distributed programming protocols. Some example embodiments mayinclude remote procedure calls being used to implement one or more ofthese components across a distributed programming environment. Forexample, a logic level may reside on a first computer system that isremotely located from a second computer system containing an interfacelevel (e.g., a graphical user interface). These first and secondcomputer systems can be configured in a server-client, peer-to-peer, orsome other configuration. The clients can vary in complexity from mobileand handheld devices, to thin clients and on to thick clients or evenother servers.

The above-illustrated software components are tangibly stored on acomputer readable storage medium as instructions. The term “computerreadable storage medium” should be taken to include a single medium ormultiple media that stores one or more sets of instructions. The term“computer readable storage medium” should be taken to include anyphysical article that is capable of undergoing a set of physical changesto physically store, encode, or otherwise carry a set of instructionsfor execution by a computer system which causes the computer system toperform any of the methods or process steps described, represented, orillustrated herein. A computer readable storage medium may be anon-transitory computer readable storage medium. Examples of anon-transitory computer readable storage media include, but are notlimited to: magnetic media, such as hard disks, floppy disks, andmagnetic tape; optical media such as CD-ROMs, DVDs and holographicdevices; magneto-optical media; and hardware devices that are speciallyconfigured to store and execute, such as application-specific integratedcircuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAMdevices. Examples of computer readable instructions include machinecode, such as produced by a compiler, and files containing higher-levelcode that are executed by a computer using an interpreter. For example,an embodiment may be implemented using Java, C++, or otherobject-oriented programming language and development tools. Anotherembodiment may be implemented in hard-wired circuitry in place of, or incombination with machine readable software instructions.

FIG. 4 is a block diagram of an exemplary computer system 400. Thecomputer system 400 includes a processor 405 that executes softwareinstructions or code stored on a computer readable storage medium 455 toperform the above-illustrated methods. The processor 405 can include aplurality of cores. The computer system 400 includes a media reader 440to read the instructions from the computer readable storage medium 455and store the instructions in storage 410 or in random access memory(RAM) 415. The storage 410 provides a large space for keeping staticdata where at least some instructions could be stored for laterexecution. According to some embodiments, such as some in-memorycomputing system embodiments, the RAM 415 can have sufficient storagecapacity to store much of the data required for processing in the RAM415 instead of in the storage 410. In some embodiments, all of the datarequired for processing may be stored in the RAM 415. The storedinstructions may be further compiled to generate other representationsof the instructions and dynamically stored in the RAM 415. The processor405 reads instructions from the RAM 415 and performs actions asinstructed. According to one embodiment, the computer system 400 furtherincludes an output device 425 (e.g., a display) to provide at least someof the results of the execution as output including, but not limited to,visual information to users and an input device 430 to provide a user oranother device with means for entering data and/or otherwise interactwith the computer system 400. Each of these output devices 425 and inputdevices 430 could be joined by one or more additional peripherals tofurther expand the capabilities of the computer system 400. A networkcommunicator 435 may be provided to connect the computer system 400 to anetwork 450 and in turn to other devices connected to the network 450including other clients, servers, data stores, and interfaces, forinstance. The modules of the computer system 400 are interconnected viaa bus 445. Computer system 400 includes a data source interface 420 toaccess data source 460. The data source 460 can be accessed via one ormore abstraction layers implemented in hardware or software. Forexample, the data source 460 may be accessed by network 450. In someembodiments the data source 460 may be accessed via an abstractionlayer, such as, a semantic layer.

A data source is an information resource. Data sources include sourcesof data that enable data storage and retrieval. Data sources may includedatabases, such as, relational, transactional, hierarchical,multi-dimensional (e.g., OLAP), object oriented databases, and the like.Further data sources include tabular data (e.g., spreadsheets, delimitedtext files), data tagged with a markup language (e.g., XML data),transactional data, unstructured data (e.g., text files, screenscrapings), hierarchical data (e.g., data in a file system, XML data),files, a plurality of reports, and any other data source accessiblethrough an established protocol, such as, Open DataBase Connectivity(ODBC), produced by an underlying software system (e.g., ERP system),and the like. Data sources may also include a data source where the datais not tangibly stored or otherwise ephemeral such as data streams,broadcast data, and the like. These data sources can include associateddata foundations, semantic layers, management systems, security systemsand so on.

In the above description, numerous specific details are set forth toprovide a thorough understanding of embodiments. One skilled in therelevant art will recognize, however that the embodiments can bepracticed without one or more of the specific details or with othermethods, components, techniques, etc. In other instances, well-knownoperations or structures are not shown or described in details.

Although the processes illustrated and described herein include seriesof steps, it will be appreciated that the different embodiments are notlimited by the illustrated ordering of steps, as some steps may occur indifferent orders, some concurrently with other steps apart from thatshown and described herein. In addition, not all illustrated steps maybe required to implement a methodology in accordance with the one ormore embodiments. Moreover, it will be appreciated that the processesmay be implemented in association with the apparatus and systemsillustrated and described herein as well as in association with othersystems not illustrated.

The above descriptions and illustrations of embodiments, including whatis described in the Abstract, is not intended to be exhaustive or tolimit the one or more embodiments to the precise forms disclosed. Whilespecific embodiments and examples are described herein for illustrativepurposes, various equivalent modifications are possible, as thoseskilled in the relevant art will recognize. These modifications can bemade in light of the above detailed description. Rather, the scope is tobe determined by the following claims, which are to be interpreted inaccordance with established doctrines of claim construction.

What is claimed is:
 1. A computer implemented method to receive datathrough a plurality of connections, the method comprising: receiving arequest to establish the plurality of connections; sending a response tothe request comprising an identifier of an upload operation and alocation to be polled for status of the upload operation; creating aplurality of connection reader threads corresponding to the plurality ofconnections, wherein the plurality of connection reader threadscorresponds to a plurality of server buffers; receiving a sequence ofchunks at the plurality of connection reader threads through theplurality of connections, wherein each of the plurality of connectionsis associated with the identifier of the upload operation; reading, viaa connection reader thread of the plurality of connection readerthreads, one or more chunks from the sequence of chunks; writing the oneor more chunks from the sequence of chunks to a server buffer of theplurality of server buffers, wherein the connection reader thread fromthe plurality of connection reader threads corresponds to the serverbuffer; searching in the plurality of server buffers for a chunk with aconsecutive number expected next for an output data stream; when thechunk with the consecutive number expected next is missing in theplurality of server buffers, blocking the connection reader thread andthe server buffer until the chunk with the consecutive number expectednext is read by a different connection reader thread of the plurality ofconnection reader threads; when the chunk with the consecutive numbernext expected is read by the different connection reader thread, addingthe chunk with the consecutive number expected next to the output datastream; and merging chunks from the plurality of server buffers into theoutput data stream according to the sequence.
 2. The method of claim 1,wherein receiving the sequence of chunks at the plurality of connectionreader threads further comprises: at a client system: reading in chunksan input data stream by a feeder thread, wherein a chunk from thesequence of chunks includes a chunk identifier representing aconsecutive number of the chunk in the sequence and a size of the chunk;writing the sequence of chunks into a client buffer, wherein thesequence of chunks to be read from the client buffer by a plurality ofconnection sender threads; and upon reading the input data stream, thefeeder thread notifying the plurality of connections that the input datastream has been read.
 3. The method of claim 1, further comprising: upondetermining that a consecutive number of the read chunk is next in thesequence of chunks expected, rebuilding an input data stream by mergingthe read chunk to the output data stream according to the sequence ofchunks.
 4. The method of claim 1, further comprising: upon determiningthat a consecutive number of the read chunk is different from anexpected consecutive number, writing the chunk to a corresponding serverbuffer from the plurality of server buffers.
 5. The method of claim 1further comprising: when the plurality of connections is closed,receiving a polling request for the status of the upload operation,wherein the polling request comprises the identifier of the uploadoperation; and sending a response comprising the status of the uploadoperation.
 6. A computer system to receive data by a plurality ofconnections, the system comprising: a memory to store computerexecutable instructions; at least one computer processor coupled to thememory to execute the instructions, to perform operations comprising:receiving a request to establish the plurality of connections; sending aresponse to the request comprising an identifier of an upload operationand a location to be polled for status of the upload operation; creatinga plurality of connection reader threads corresponding to the pluralityof connections, wherein the plurality of connection reader threadscorresponds to a plurality of server buffers; receiving a sequence ofchunks at the plurality of connection reader threads through theplurality of connections, wherein each of the plurality of connectionsis associated with the identifier of the upload operation; reading, viaa connection reader thread of the plurality of connection readerthreads, one or more chunks from the sequence of chunks; writing the oneor more chunks from the sequence of chunks to a server buffer of theplurality of server buffers, wherein the connection reader thread fromthe plurality of connection reader threads corresponds to the serverbuffer; searching in the plurality of server buffers for a chunk with aconsecutive number expected next for an output data stream; when thechunk with the consecutive number expected next is missing in theplurality of server buffers, blocking the connection reader thread andthe server buffer until the chunk with the consecutive number expectednext is read by a different connection reader thread of the plurality ofconnection reader threads; when the chunk with the consecutive numberexpected next is read by the different connection reader thread, addingthe chunk with the consecutive number expected next to the output datastream; and merging chunks from the plurality of server buffers into theoutput data stream.
 7. The system of claim 6, wherein the operationsfurther comprising: at a client system: reading in chunks an input datastream by a feeder thread, wherein a chunk from the sequence of chunksincludes a chunk identifier representing a consecutive number of thechunk in the sequence and a size of the chunk; writing the sequence ofchunks into a client buffer, wherein the sequence of chunks to be readfrom the client buffer by a plurality of connection sender threads; andupon reading the input data stream, the feeder thread notifying theplurality of connections that the input data stream has been read. 8.The system of claim 6, wherein: the plurality of server buffers to storechunks transferred by the plurality of connection reader threads, andthe corresponding connection reader thread from the plurality ofconnection reader threads reading a chunk from the one or more chunkssent by a corresponding connection sender thread from a plurality ofconnection sender threads.
 9. The system of claim 8, wherein theoperations further comprising: upon determining that a consecutivenumber of the read chunk is next in the sequence of chunks expected,rebuilding an input data stream by merging the read chunk to the outputdata stream according to the sequence of chunks.
 10. The system of claim8, wherein the operations further comprising: upon determining that aconsecutive number of the read chunk is different from the expectedconsecutive number, writing the chunk to a corresponding server bufferfrom the plurality of server buffers.
 11. The system of claim 6, whereinthe operations further comprising: when the plurality of connections isclosed, receive a polling request for the status of the uploadoperation, wherein the polling request comprises the identifier of theupload operation; and send a response comprising the status of theupload operation.
 12. A non-transitory computer readable storage mediumhaving instructions encoded thereon that, when executed by a processor,cause the processor to perform operations comprising: receive a requestto establish a plurality of connections; send a response to the requestcomprising an identifier of an upload operation and a location to bepolled for status of the upload operation; create a plurality ofconnection reader threads corresponding to the plurality of connections,wherein the plurality of connection reader threads corresponds to aplurality of server buffers; receive a sequence of chunks at theplurality of connection reader threads through the plurality ofconnections, wherein each of the connections of the plurality ofconnections is associated with the identifier of the upload operation;read, via a connection reader thread of the plurality of connectionreader threads, one or more chunks from the sequence of chunks; writethe one or more chunks from the sequence of chunks to a server buffer ofthe plurality of server buffers, wherein the connection reader threadfrom the plurality of connection reader threads corresponds to theserver buffer; search in the plurality of server buffers for a chunkwith a consecutive number expected next for an output data stream; whenthe chunk with the consecutive number expected next is missing in theplurality of server buffers, block the connection reader thread and theserver buffer until the chunk with the consecutive number expected nextis read by a different connection reader thread of the plurality ofconnection reader threads; when the chunk with the consecutive numberexpected next is read by the different connection reader thread, add thechunk with the consecutive number expected next to the output datastream; and merge chunks from the plurality of server buffers into theoutput data stream.